⚠️ Potential issue | 🟠 Major

Null-check GetShardHeap() before dereferencing.

GetShardHeap() can return nullptr if InitializeShardHeap() hasn't been called yet. The existing guards (memory_limit_ == 0, data_key_count_ == 0) don't guarantee the heap is initialized.

Additionally, allocated is int64_t — if it's zero or negative (edge case), casting allocated * dirty_key_ratio to uint64_t on Line 444 would produce an incorrect large value.

 void CcShard::CheckAndTriggerCkptByDirtyMemory()
 {
     if (memory_limit_ == 0 || data_key_count_ == 0 || ckpter_ == nullptr)
     {
         return;
     }
 
+    if (GetShardHeap() == nullptr)
+    {
+        return;
+    }
+
     // Get current memory usage
     int64_t allocated = 0, committed = 0;
     GetShardHeap()->Full(&allocated, &committed);
 
+    if (allocated <= 0)
+    {
+        return;
+    }
+
     // Calculate dirty memory

In `@tx_service/src/cc/cc_shard.cpp` around lines 430 - 469, In
CcShard::CheckAndTriggerCkptByDirtyMemory, add a nullptr check for
GetShardHeap() before calling Full() and return early if it is null to avoid
dereferencing an uninitialized heap; also guard the allocated value (returned by
Full()) so that if allocated <= 0 you treat it as 0 (or clamp to 0) before
computing dirty_memory and casting to uint64_t to avoid producing a huge
unsigned value when allocated is negative; update the dirty_memory calculation
to use the clamped allocated value and keep the rest of the threshold logic and
ckpter_->Notify(true) behavior unchanged.

⚠️ Potential issue | 🟡 Minor

threshold may be zero when memory_limit_ is small.

When FLAGS_dirty_memory_size_threshold_mb == 0, the threshold is memory_limit_ * 0.1. If memory_limit_ is very small (e.g., < 10 bytes in a test), the truncation to uint64_t yields 0, making dirty_memory > threshold trivially true and spamming checkpoint notifications. Consider a minimum floor or an early return.

In `@tx_service/src/cc/cc_shard.cpp` around lines 446 - 455, The computed
threshold in the shard's checkpoint logic (variable threshold computed from
FLAGS_dirty_memory_size_threshold_mb and memory_limit_) can become zero for tiny
memory_limit_ values, causing dirty_memory > threshold to always be true; update
the calculation in cc_shard.cpp (the block that sets threshold using
memory_limit_ and FLAGS_dirty_memory_size_threshold_mb) to enforce a reasonable
minimum floor (e.g., a constant MIN_DIRTY_THRESHOLD_BYTES) or early-return when
the computed threshold would be zero so you don't trigger spurious checkpoint
notifications; ensure you reference memory_limit_,
FLAGS_dirty_memory_size_threshold_mb, and the local variable threshold when
making the change.

⚠️ Potential issue | 🟡 Minor

Narrowing from uint64_t to uint32_t when inserting into tx_service_conf.

The map is std::map<std::string, uint32_t>, but dirty_memory_check_interval and dirty_memory_size_threshold_mb are uint64_t. Values exceeding UINT32_MAX will be silently truncated. This is unlikely to be a practical problem for these specific settings, and other entries in this map already have the same narrowing pattern (e.g., checkpointer_interval), but worth noting for correctness.

If the map's value type can't be widened (to avoid a larger refactor), consider adding a static_assert or runtime check clamping these values to UINT32_MAX before insertion.

In `@core/src/tx_service_init.cpp` around lines 232 - 234, The map tx_service_conf
is typed std::map<std::string, uint32_t> but variables
dirty_memory_check_interval and dirty_memory_size_threshold_mb are uint64_t,
risking silent truncation; fix by either (A) clamping/casting the two values to
uint32_t with a runtime check that if value > UINT32_MAX it is set to UINT32_MAX
(and optionally log/warn) before inserting into tx_service_conf, or (B) add a
static_assert or explicit runtime assertion near the definitions of
dirty_memory_check_interval/dirty_memory_size_threshold_mb to ensure they never
exceed UINT32_MAX; update the insertion code that uses the keys
"dirty_memory_check_interval" and "dirty_memory_size_threshold_mb" accordingly
(perform clamp or assert prior to populating tx_service_conf).

just clear adjust_stats_call_count_ when it reaches check interval to avoid expensive % call

this should be pre calculated at cc shard initialization

you should not spam notify when there's already a checkpoint ongoing

why do you need 2 fields here?

dirty_memory_check_interval_: check dirty memory size every 1000 times of AdjustDataKeyStats call
dirty_memory_size_threshold_mb_: trigger ckpt when dirty memory size bigger than this value

I mean dirty_memory_size_threshold_mb_ and dirty_memory_threshold_bytes_

I mean dirty_memory_threshold_bytes_ and dirty_memory_size_threshold_mb_

why is this changed to atomic? atomic and mutex + cv does not work well together

I mean dirty_memory_size_threshold_mb_ and dirty_memory_threshold_bytes_

We should keep this as a safety check. This should not trigger. But if user set some terrible params like check interval = 1000000 and dirty ratio = 99%, we might be stuck at memory full and unable to trigger checkpoint

no need to use acquire.
no need to use high_resolution_clock.
Too expensive.
Save the current timestamp so you don't have do it twice

I mean dirty_memory_threshold_bytes_ and dirty_memory_size_threshold_mb_

We should keep the memory full check as a safety check. In case some terrible params are set, like check interval = 1000000 and dirty memory ratio = 99%, we might stuck at memory full and unable to trigger checkpoint.